Files that changed from the base of the PR and between 03f7a4c and 6395f34.

• .github/dependabot.yml (1 hunks)
• .github/workflows/add-to-projects.yml (1 hunks)
• .github/workflows/dependabot.yml (1 hunks)
• .github/workflows/test.yml (1 hunks)
• .gitignore (1 hunks)
• .pre-commit-config.yaml (1 hunks)
• .terraform-docs.yml (1 hunks)
• README.md (1 hunks)
• SECURITY.md (1 hunks)
• dns/main.tf (1 hunks)
• dns/outputs.tf (1 hunks)
• dns/variables.tf (1 hunks)
• locals.tf (1 hunks)
• main.tf (1 hunks)
• outputs.tf (1 hunks)
• regional/README.md (1 hunks)
• regional/main.tf (1 hunks)
• regional/nat/README.md (1 hunks)
• regional/nat/locals.tf (1 hunks)
• regional/nat/main.tf (1 hunks)
• regional/nat/outputs.tf (1 hunks)
• regional/nat/variables.tf (1 hunks)
• regional/outputs.tf (1 hunks)
• regional/variables.tf (1 hunks)
• tests/default.tftest.hcl (1 hunks)
• tests/fixtures/default/dns/main.tf (1 hunks)
• tests/fixtures/default/dns/variables.tf (1 hunks)
• tests/fixtures/default/main.tf (1 hunks)
• tests/fixtures/default/regional/main.tf (1 hunks)
• tests/fixtures/default/regional/outputs.tf (1 hunks)
• tests/fixtures/default/regional/variables.tf (1 hunks)
• tests/fixtures/default/regional_nat/main.tf (1 hunks)
• tests/fixtures/default/regional_nat/outputs.tf (1 hunks)
• tests/fixtures/default/regional_nat/variables.tf (1 hunks)
• tests/fixtures/default/variables.tf (1 hunks)
• variables.tf (1 hunks)

• .github/dependabot.yml
• .gitignore
• .terraform-docs.yml
• SECURITY.md
• dns/outputs.tf
• regional/nat/locals.tf
• regional/outputs.tf
• tests/fixtures/default/dns/variables.tf
• tests/fixtures/default/regional/outputs.tf
• tests/fixtures/default/regional/variables.tf
• tests/fixtures/default/regional_nat/outputs.tf
• tests/fixtures/default/regional_nat/variables.tf
• tests/fixtures/default/variables.tf

regional/nat/outputs.tf (2)

4-7: The output block for name is solid.

The description is clear, and the value correctly references local.name. Keep it up.

---

9-12: The output block for project is well-defined.

The description is clear, and the value correctly references var.project. Nice work.

.github/workflows/dependabot.yml (4)

1-1: The workflow name is fitting.

The name Dependabot Approve and Merge is descriptive and aligns with the workflow's purpose. Good choice.

---

3-3: The workflow trigger is appropriate.

Triggering on pull_request_target is suitable for this workflow. Well done.

---

5-7: The workflow permissions are minimal and appropriate.

Granting read permissions for contents is a good practice. Nice job.

---

8-13: The workflow job is well-defined.

The job dependabot is correctly defined using the external workflow and the secret is properly referenced. Solid work.

.github/workflows/add-to-projects.yml (4)

1-1: The workflow name is appropriate.

The name Add To GitHub Projects is descriptive and aligns with the workflow's purpose. Good choice.

---

3-10: The workflow triggers are suitable.

Triggering on issues and pull_request events is appropriate for this workflow. Well done.

---

11-13: The workflow permissions are appropriate.

Granting write permissions for issues is suitable for this workflow. Nice job.

---

14-21: The workflow job is well-defined.

The job add-to-osinfra-project is correctly defined using the external workflow and the secret is properly referenced. Solid work.

outputs.tf (3)

4-7: This is good work.

The output block for the network name is correctly defined.

---

9-12: Nice job.

The output block for the project ID is correctly defined.

---

14-17: This is well done.

The output block for the URI of the created resource is correctly defined.

.github/workflows/test.yml (4)

1-10: Good choice of triggers.

The workflow is appropriately triggered on workflow_dispatch and pull_request events.

---

12-14: Necessary permissions granted.

The workflow requests the appropriate id-token: write permission.

---

20-23: Inputs are well-defined.

The job inputs are correctly defined and necessary for the job.

---

15-23: Looks good, but verify the external workflow.

The job configuration appears correct, but ensure the external workflow is trustworthy.

tests/fixtures/default/regional_nat/main.tf (3)

1-10: Provider configuration is correct.

The required provider hashicorp/google is correctly specified.

---

12-18: Module configuration is correct.

The module all_subnets_test is correctly configured.

---

20-29: Module configuration is correct.

The module list_of_subnets_test is correctly configured.

dns/main.tf (2)

23-33: Review private visibility configuration.

The dynamic block configures private visibility based on the provided networks. Ensure that the provided networks are correctly defined and the logic aligns with your requirements.

---

16-21: Ensure DNSSEC is enabled only for public zones.

The dynamic block enables DNSSEC only for public zones. Verify that this logic aligns with your security requirements.

Verification successful

---

DNSSEC is enabled only for public zones.

The dynamic block in dns/main.tf ensures DNSSEC is enabled only when var.visibility is "public", aligning with the security requirements.

• dns/main.tf: Lines 16-21

Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify that DNSSEC is enabled only for public zones.

# Test: Search for the usage of `dnssec_config`. Expect: DNSSEC is enabled only for public zones.
rg --type terraform 'dnssec_config'

Length of output: 69

---

Script:

#!/bin/bash
# Description: Verify that DNSSEC is enabled only for public zones.

# Test: Search for the usage of `dnssec_config` in Terraform files.
rg 'dnssec_config' --glob '*.tf'

Length of output: 72

---

Script:

#!/bin/bash
# Description: Verify the definition and usage of `var.visibility` to ensure it correctly identifies public zones.

# Search for the definition of `var.visibility` in Terraform files.
rg 'variable "visibility"' --glob '*.tf'

# Search for the usage of `var.visibility` in Terraform files.
rg 'var.visibility' --glob '*.tf'

Length of output: 350

.pre-commit-config.yaml (5)

16-17: Ensure Terraform formatting hook is necessary.

The terraform_fmt hook ensures that Terraform files are properly formatted. Verify its necessity for your project.

Verification successful

---

The terraform_fmt hook is necessary.

Given the presence of multiple Terraform files in the project, the terraform_fmt hook is essential to ensure proper formatting and maintain code quality.

• .pre-commit-config.yaml: Line 16-17

Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify the necessity of Terraform formatting hook.

# Test: Search for the usage of Terraform formatting hook. Expect: Hook is necessary for the project.
rg --type yaml 'terraform_fmt'

Length of output: 80

---

Script:

#!/bin/bash
# Description: Verify the presence of Terraform files in the project.

# Test: Search for Terraform files (.tf) in the project. Expect: Terraform files are present.
fd --extension tf

Length of output: 668

---

34-37: Ensure Checkov hook is properly configured.

The checkov hook includes arguments for verbosity and quiet mode. Verify that these configurations align with your requirements.

---

29-30: Ensure Terraform documentation generation hook is necessary.

The terraform_docs hook generates documentation for Terraform files. Verify its necessity for your project.

---

21-25: Ensure Terraform validation hook is properly configured.

The terraform_validate hook includes arguments for retrying and upgrading. Verify that these configurations align with your requirements.

Verification successful

---

The Terraform validation hook is properly configured.

The terraform_validate hook in the .pre-commit-config.yaml file includes the necessary arguments for retrying and upgrading, and it excludes the tests/fixtures/shared directory as expected.

• Configuration Block:

  - id: terraform_validate
    args:
      - --hook-config=--retry-once-with-cleanup=true
      - --tf-init-args=-upgrade
    exclude: tests/fixtures/shared

Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify the configurations of Terraform validation hook.

# Test: Search for the usage of Terraform validation hook. Expect: Hook is properly configured.
rg --type yaml 'terraform_validate'

Length of output: 158

---

Script:

#!/bin/bash
# Description: Extract the entire configuration block of the terraform_validate hook.

# Extract the configuration block of terraform_validate hook from .pre-commit-config.yaml
sed -n '/- id: terraform_validate/,/^$/p' .pre-commit-config.yaml

Length of output: 245

---

8-11: Ensure hooks are relevant and necessary.

The hooks check-yaml, end-of-file-fixer, trailing-whitespace, and check-symlinks are useful for maintaining code quality. Verify their necessity and relevance for your project.

regional/nat/variables.tf (6)

4-7: Ensure network variable is correctly defined.

The network variable is defined as a string. Verify that this aligns with your requirements.

Verification successful

Alright, let's try this again. We need to make sure that the network variable is correctly defined and used in the Terraform files. Let's search for the network variable in all .tf files.

---

The network variable is correctly defined and used.

The network variable is defined as a string and is actively used in the codebase, aligning with the requirements.

• Definition found in regional/nat/variables.tf and regional/variables.tf.
• Usage found in regional/nat/locals.tf, regional/main.tf, and regional/nat/main.tf.

Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify the definition of network variable.

# Test: Search for the usage of network variable. Expect: Variable is correctly defined.
rg --type terraform 'variable "network"'

Length of output: 76

---

Script:

#!/bin/bash
# Description: Verify the definition and usage of network variable in Terraform files.

# Search for the definition of the network variable.
rg 'variable "network"' --glob '*.tf' -A 3

# Search for the usage of the network variable.
rg 'var.network' --glob '*.tf' -A 3

Length of output: 1285

---

31-35: Ensure subnetwork_names variable default value is appropriate.

The subnetwork_names variable has a default value of an empty list. Verify that this aligns with your requirements.

Verification successful

---

The default value of subnetwork_names is appropriate.

The subnetwork_names variable is conditionally used in the codebase, and its default value of an empty list aligns with the intended functionality. The test fixture demonstrates that it can be overridden with specific values when needed.

• regional/nat/variables.tf
• regional/nat/README.md
• regional/nat/main.tf
• tests/fixtures/default/regional_nat/main.tf

Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify the default value of subnetwork_names variable.

# Test: Search for the usage of subnetwork_names variable. Expect: Default value is appropriate.
rg --type terraform 'variable "subnetwork_names"'

Length of output: 85

---

Script:

#!/bin/bash
# Description: Verify the default value of subnetwork_names variable.

# Test: Search for the usage of subnetwork_names variable across all files.
rg 'subnetwork_names'

Length of output: 586

---

25-29: Ensure source_subnetwork_ip_ranges_to_nat variable default value is appropriate.

The source_subnetwork_ip_ranges_to_nat variable has a default value of ALL_SUBNETWORKS_ALL_IP_RANGES. Verify that this aligns with your requirements.

Verification successful

---

The default value of source_subnetwork_ip_ranges_to_nat is appropriate.

The variable source_subnetwork_ip_ranges_to_nat is set to ALL_SUBNETWORKS_ALL_IP_RANGES by default, which is suitable for general configurations. Specific configurations, such as those in the test fixtures, can override this default as needed.

• regional/nat/variables.tf: Defines the variable with the default value.
• regional/nat/main.tf: Uses the variable and includes conditional logic for different values.
• tests/fixtures/default/regional_nat/main.tf: Overrides the default value for specific test cases.

Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify the default value of source_subnetwork_ip_ranges_to_nat variable.

# Test: Search for the usage of source_subnetwork_ip_ranges_to_nat variable. Expect: Default value is appropriate.
rg --type terraform 'variable "source_subnetwork_ip_ranges_to_nat"'

Length of output: 103

---

Script:

#!/bin/bash
# Description: Verify the default value of source_subnetwork_ip_ranges_to_nat variable.

# Test: Search for the usage of source_subnetwork_ip_ranges_to_nat variable in all files and filter out Terraform files.
rg 'source_subnetwork_ip_ranges_to_nat' --glob '*.tf' -A 5

Length of output: 1599

---

9-13: Ensure prefix variable default value is appropriate.

The prefix variable has a default value of an empty string. Verify that this aligns with your requirements.

Verification successful

Alright, let's get this right. We need to find where this prefix variable is being used in the Terraform files. We'll search through all files and then filter for the ones we need.

---

Alright, let's make sure we find this prefix variable in the Terraform files. We'll search directly within all .tf files to see where it's being used.

---

The default value of the prefix variable is appropriate.

The prefix variable is defined with a default value of an empty string, which is correctly handled in the codebase. Specifically:

• In regional/nat/locals.tf, if var.prefix is an empty string, it defaults to var.network.
• In tests/fixtures/default/regional_nat/main.tf, a specific prefix value is set for testing.

No issues found with the default value.

Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify the default value of prefix variable.

# Test: Search for the usage of prefix variable. Expect: Default value is appropriate.
rg --type terraform 'variable "prefix"'

Length of output: 75

---

Script:

#!/bin/bash
# Description: Verify the default value of prefix variable.

# Search for the usage of 'prefix' variable in all files and filter for Terraform files.
rg 'prefix' | grep -E '\.tf$'

Length of output: 29

---

Script:

#!/bin/bash
# Description: Verify the default value of prefix variable.

# Search for the usage of 'prefix' variable in all Terraform files.
rg 'prefix' --glob '*.tf'

Length of output: 434

---

15-18: Ensure project variable is correctly defined.

The project variable is defined as a string. Verify that this aligns with your requirements.

---

20-23: Ensure region variable is correctly defined.

The region variable is defined as a string. Verify that this aligns with your requirements.

Verification successful

Alright, here's what we're gonna do. We're gonna run a different script to find that region variable definition. This time, we'll do it right.

---

Alright, let's take a closer look at these definitions, make sure everything's in order.

---

Alright, let's fix this up and do it right. We'll get those definitions with some context.

---

The region variable is correctly defined.

The region variable is defined as a string in both regional/variables.tf and regional/nat/variables.tf, aligning with the requirements.

• regional/variables.tf: "The region for this subnetwork"
• regional/nat/variables.tf: "The region in which the resource belongs"

Both definitions are appropriate for their respective contexts. No issues found.

Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify the definition of region variable.

# Test: Search for the usage of region variable. Expect: Variable is correctly defined.
rg --type terraform 'variable "region"'

Length of output: 75

---

Script:

#!/bin/bash
# Description: Verify the definition of region variable.

# Test: Search for the usage of region variable in all Terraform files.
rg 'variable "region"' --glob '*.tf'

Length of output: 126

---

Script:

#!/bin/bash
# Description: Display the definitions of the region variable in both files.

# Display the definition in regional/variables.tf
echo "Definition in regional/variables.tf:"
rg 'variable "region" {[^}]*}' -z -o --glob 'regional/variables.tf'

# Display the definition in regional/nat/variables.tf
echo "Definition in regional/nat/variables.tf:"
rg 'variable "region" {[^}]*}' -z -o --glob 'regional/nat/variables.tf'

Length of output: 567

---

Script:

#!/bin/bash
# Description: Display the definitions of the region variable in both files with context.

# Display the definition in regional/variables.tf with context lines
echo "Definition in regional/variables.tf:"
rg 'variable "region"' -A 3 --glob 'regional/variables.tf'

# Display the definition in regional/nat/variables.tf with context lines
echo "Definition in regional/nat/variables.tf:"
rg 'variable "region"' -A 3 --glob 'regional/nat/variables.tf'

Length of output: 685

tests/default.tftest.hcl (3)

37-47: Good job on the regional run block.

The run block is straightforward and applies the regional module. The variable project is correctly set.

However, verify that the module source path ./tests/fixtures/default/regional is correct and contains the necessary Terraform configuration.

Verification successful

---

You did well, kid. The module source path ./tests/fixtures/default/regional is correct and contains the necessary Terraform configuration files.

• main.tf
• outputs.tf
• variables.tf

You can proceed with confidence.

Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify the module source path for the regional run block.

# Test: Check if the directory exists. Expect: Directory exists.
if [ -d "./tests/fixtures/default/regional" ]; then
  echo "Directory exists."
else
  echo "Directory does not exist."
fi

Length of output: 91

---

Script:

#!/bin/bash
# Description: Verify the contents of the module source path for the regional run block.

# Test: List the contents of the directory and check for expected Terraform configuration files.
ls ./tests/fixtures/default/regional

Length of output: 70

---

3-22: Good job on the default run block.

The assertions ensure that the module's outputs match the expected values. The variable project is correctly set.

However, verify that the module source path ./tests/fixtures/default is correct and contains the necessary Terraform configuration.

Verification successful

Listen, the directory ./tests/fixtures/default exists. That's good. But we need to make sure it contains the necessary Terraform configuration. Let's take a look inside, see what we got.

---

Good job on the default run block.

The assertions ensure that the module's outputs match the expected values. The variable project is correctly set. The module source path ./tests/fixtures/default is correct and contains the necessary Terraform configuration files, including main.tf and variables.tf.

Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify the module source path for the default run block.

# Test: Check if the directory exists. Expect: Directory exists.
if [ -d "./tests/fixtures/default" ]; then
  echo "Directory exists."
else
  echo "Directory does not exist."
fi

Length of output: 82

---

Script:

#!/bin/bash
# Description: List the contents of the module source path for the default run block.

# Test: List files in the directory. Expect: Terraform configuration files present.
ls -l ./tests/fixtures/default

Length of output: 332

---

49-59: Good job on the regional NAT run block.

The run block is straightforward and applies the regional NAT module. The variable project is correctly set.

However, verify that the module source path ./tests/fixtures/default/regional_nat is correct and contains the necessary Terraform configuration.

Verification successful

Good job on the regional NAT run block.

The run block is straightforward and applies the regional NAT module. The variable project is correctly set.

However, let's make sure that the module source path ./tests/fixtures/default/regional_nat contains the necessary Terraform configuration files.

---

Good job on the regional NAT run block.

The run block is straightforward and applies the regional NAT module. The variable project is correctly set. The module source path ./tests/fixtures/default/regional_nat is verified and contains the necessary Terraform configuration files.

Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify the module source path for the regional NAT run block.

# Test: Check if the directory exists. Expect: Directory exists.
if [ -d "./tests/fixtures/default/regional_nat" ]; then
  echo "Directory exists."
else
  echo "Directory does not exist."
fi

Length of output: 95

---

Script:

#!/bin/bash
# Description: Verify the presence of Terraform configuration files in the module source path for the regional NAT run block.

# Test: List the contents of the directory and check for .tf files. Expect: At least one .tf file exists.
if ls ./tests/fixtures/default/regional_nat/*.tf 1> /dev/null 2>&1; then
  echo "Terraform configuration files found."
else
  echo "No Terraform configuration files found."
fi

Length of output: 233

regional/main.tf (1)

4-35: Good job on the Google Compute subnetwork resource block.

The resource block is comprehensive and correctly sets up a subnetwork with appropriate configurations and dynamic blocks for secondary IP ranges and log configurations.

regional/nat/main.tf (2)

4-9: Resource definition looks good.

The google_compute_router resource is defined correctly with appropriate attributes.

---

14-36: Resource definition looks good.

The google_compute_router_nat resource is defined correctly with appropriate attributes and dynamic subnetwork blocks.

dns/variables.tf (7)

1-5: Variable definition looks good.

The description variable is defined correctly with an appropriate default value.

---

7-10: Variable definition looks good.

The dns_name variable is defined correctly with a clear and accurate description.

---

12-16: Variable definition looks good.

The labels variable is defined correctly with an appropriate default value.

---

18-21: Variable definition looks good.

The name variable is defined correctly with a clear and accurate description.

---

23-27: Variable definition looks good.

The private_visibility_config_networks variable is defined correctly with an appropriate default value.

---

29-32: Variable definition looks good.

The project variable is defined correctly with a clear and accurate description.

---

34-37: Variable definition looks good.

The visibility variable is defined correctly with a clear and accurate description.

tests/fixtures/default/regional/main.tf (1)

12-41: Module definition looks good.

The test module is defined correctly with appropriate attributes and configurations.

variables.tf (4)

1-5: This variable is well-defined.

The name variable has a clear description, type, and default value.

---

11-35: This variable is well-defined.

The rules variable has a clear description, type, and default value, and it follows best practices for complex types.

---

37-41: This variable is well-defined.

The shared_vpc variable has a clear description, type, and default value.

---

43-47: This variable is well-defined.

The shared_vpc_service_projects variable has a clear description, type, and default value.

locals.tf (2)

4-35: The rule for Google Cloud Load Balancer health check probes is well-defined.

The rule includes necessary ports, protocols, and IP ranges.

---

37-58: The rule for remote SSH access via Google Cloud IAP is well-defined.

The rule includes necessary ports, protocols, and IP ranges.

regional/variables.tf (9)

4-7: This variable is well-defined.

The ip_cidr_range variable has a clear description and type.

---

9-12: This variable is well-defined.

The name variable has a clear description and type.

---

14-17: This variable is well-defined.

The network variable has a clear description and type.

---

19-23: This variable is well-defined.

The private_ip_google_access variable has a clear description, type, and default value.

---

25-28: This variable is well-defined.

The project variable has a clear description and type.

---

30-34: This variable is well-defined.

The purpose variable has a clear description, type, and default value.

---

36-39: This variable is well-defined.

The region variable has a clear description and type.

---

41-45: This variable is well-defined.

The role variable has a clear description, type, and default value.

---

47-54: This variable is well-defined.

The secondary_ip_ranges variable has a clear description, type, and default value, and it follows best practices for complex types.

tests/fixtures/default/main.tf (3)

1-10: Good job setting up the providers.

The provider requirements and module source are defined correctly.

---

21-42: Firewall rules are well-defined.

The firewall rules cover various scenarios and are correctly configured.

---

73-77: Clear instructions for shared VPC configuration.

The comments provide clear instructions for shared VPC configuration.

regional/nat/README.md (5)

1-8: Clear introduction and requirements.

The introduction and requirements sections are clear and correctly state that no requirements are needed.

---

10-15: Providers section is accurate.

The providers section lists the Google provider with version 5.38.0, which matches the configuration.

---

16-19: Modules section is accurate.

The modules section correctly states that no modules are used.

---

20-26: Resources section is accurate.

The resources section lists the Google Compute Router and NAT resources correctly.

---

27-44: Inputs and outputs sections are detailed and accurate.

The inputs and outputs sections provide necessary information and are correctly defined.

main.tf (4)

1-40: Firewall resource is well-defined with dynamic blocks.

The firewall resource is correctly configured with dynamic blocks for allow, deny, and log_config.

---

42-50: Network resource is correctly configured.

The network resource is defined with auto_create_subnetworks set to false and routing_mode set to GLOBAL, which follows best practices.

---

52-59: Shared VPC host project resource is correctly configured.

The shared VPC host project resource is defined with a conditional count based on the shared_vpc variable, which follows best practices.

---

61-69: Shared VPC service project resource is correctly configured.

The shared VPC service project resource is defined with a conditional for_each based on the shared_vpc variable, which follows best practices.

regional/README.md (6)

6-8: No requirements specified.

This section is clear and concise.

---

10-15: Provider details are clear.

This section is well-documented.

---

16-18: No modules specified.

This section is clear and concise.

---

20-25: Resource details are clear.

This section is well-documented.

---

26-38: Input parameters are well-documented.

This section is comprehensive and detailed.

Tools

LanguageTool

[typographical] ~31-~31: If specifying a range, consider using an en dash instead of a hyphen.
Context: ...the resource. The resource name must be 1-63 characters long, and comply with RFC103...

(HYPHEN_TO_EN)

---

40-46: Output parameters are well-documented.

This section is comprehensive and detailed.

README.md (7)

13-19: Repository description is clear.

This section is well-documented.

---

20-24: Usage section is clear.

This section is well-documented.

---

25-29: Development practices are well-documented.

This section is comprehensive and detailed.

Tools

LanguageTool

[uncategorized] ~29-~29: If this is a compound adjective that modifies the following noun, use a hyphen.
Context: ... engineering, Infrastructure as Code. >Open Source Infrastructure (as Code) is a developme...

(EN_COMPOUND_ADJECTIVE_INTERNAL)

---

[uncategorized] ~29-~29: If this is a compound adjective that modifies the following noun, use a hyphen.
Context: ...zations can use internally at scale. - [Open Source Infrastructure (as Code)](https://www.o...

(EN_COMPOUND_ADJECTIVE_INTERNAL)

Markdownlint

25-25: null
Images should have alternate text (alt text)

(MD045, no-alt-text)

---

35-41: Tools section is clear.

This section is well-documented.

---

43-52: Skills and knowledge section is clear.

This section is well-documented.

---

54-64: Tests section is clear.

This section is well-documented.

---

66-103: Terraform documentation is clear.

This section is well-documented.

Tools

LanguageTool

[uncategorized] ~92-~92: A punctuation mark might be missing here.
Context: ...s | List of firewall rule definitions | ```list(object({ allow = optional(list(ob...

(AI_EN_LECTOR_MISSING_PUNCTUATION)

Files that changed from the base of the PR and between 6395f34 and 9e447db.

• variables.tf (1 hunks)

• variables.tf